Mtime fixes #2667
Mtime fixes #2667
Conversation
mtime == 0 is the "this Item contains newer metadata than the file's tags" marker. Setting this to something else than 0 emulates the state of Items freshly read from the database. Breaks 4 of the edit plugin tests.
…ehaviour I was midway through writing a test when realizing that it's best the way it is...
This didn't manifest as a testing failure since the plugin (mostly silently) drops id changes.
… changes Unbreaks the remaining edit plugin tests.
|
@wordofglass, thanks for your PR! By analyzing the history of the files in this pull request, we identified @sampsyo, @wlof and @geigerzaehler to be potential reviewers. |
|
Nice work! These test fixes look good as well. Fighting through the harnesses there wasn’t easy—you deserve some kind of a badge. 🏅 This looks ready to merge to me. |
|
Ok. Would you usually write a changelog entry for this? As far as I can see, there's no user-visible change (well, file access times will be updated less frequently which might affect some rsync, but this is pretty minor IMO). |
|
In general, I do usually tend to write a changelog for even these esoteric things. I'm not sure anyone actually reads them, but it makes me happy to have a complete summary of what happened in a given release. 😃 Maybe something like this would work?
|
|
I couldn't have worded that better, I'm going to blatantly copy that to the changelog 😆 |
|
Fantastic; thank you! |
|
Ok, resolving merge conflicts on Github is apparently not the best idea. Sorry for the extra commit... |
As per #2664, the
Item.mtimeis reset for any assignment toMediaFile-backed fields, even if theItems fields and the file's tags do not go out of sync (i.e. if the previous value is reassigned). This happens frequently in theeditplugin. While the effects are not devastating, it's certainly not ideal when using the plugin with coarse queries and only changing few items in the editor.In fact,
test.test_editalready had a method to check that these superfluous tag writes didn't happen. It didn't really check this, though, since themtimefor test fixtures would always be 0 to begin with. An "mtimereset" would therefore not_dirtytheItem, and the plugin would in turn not write the tags out: In a real-world setting with non-zeromtime, these writes did happen.Some additional details can be found in the commit messages. Thoughts?
NOTE: Forgot the changelog, will add it later.